Feature limits are limits on the operational capabilities of software. Feature limits may be imposed because of limits of the underlying hardware, limits of the software, or for marketing reasons. For example, software developed for disk storage arrays may be used to copy information from one array to another array or between disks within the same array. The software may include a tier one version that allows 100 simultaneous disk copy sessions and a tier two version that allows only 50 simultaneous disk copy sessions. The developer may charge more for the tier one version to provide a customer with additional capabilities.
One method for enforcing software feature limits is to hard code the limits within the software programs. For example, the feature limit may be coded in a program as a constant. Different constants may be coded for different hardware platforms, software releases, and tiers to provide different capabilities for each combination. However, as the number of hardware platforms, software releases, and software tiers increases, hard-coded solutions unnecessarily increase the complexity of the software.
One solution for enforcing feature limits on different hardware platforms is to store a feature limit parameter in a registry present on the hardware platform and have the software read the parameter. One problem with this approach is that it does not allow different limits to be enforced based on different software tiers. In addition, if a limit is changed due to installation of a new software release. The new software may need to use the old feature limit parameter until the new software has been committed (explained below). Once the software has been committed, and there is no way to revert back to the old software, then the new limit can be used.
Still another problem associated with updating software feature limits occurs when it is desirable to upgrade directly from one release to a new release where there are intermediate releases between the existing release and the new release and where the intermediate releases and the new release have increased feature limits. For example, it may be desirable to upgrade from release 1 to release 3 where releases 2 and 3 have increased feature limits. When the system starts running release 3 code, it may be desirable to use release 1 feature limits until the release 3 software is committed. In a hard-coded solution, the release 3 software can only apply the release 3 feature limits.
Accordingly, in light of these difficulties associated with conventional methods for identifying and enforcing software feature limits, there exists a need for methods, systems, and computer program products for identifying and enforcing software feature limits across different hardware platforms, software releases, and tiers.